home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 2 / Apprentice-Release2.iso / Source Code / C / Games / Xconq 7.0d16 / doc / PROJECTS < prev    next >
Encoding:
Text File  |  1993-12-20  |  41.9 KB  |  995 lines  |  [TEXT/MPS ]

  1. PROJECT IDEAS
  2.  
  3. --GDL
  4.  
  5. Define a global "side*" that is a list of all sides.
  6.  
  7. In evals, do binding of "this" so expressions like (count <u> (this side))
  8. work.
  9.  
  10. Could restrict some tables to 15 bit integers, use top bit to repn varying
  11. value, up to 16d15+127 by doing a 4/4/7 split of bits.
  12.  
  13. Support full decimals for parms, flush the "10000" numbers and add scale
  14. factor to all numeric parms.  Scaling fixed by code, use scaling when
  15. computing effects.
  16. Ambiguity if context of decimal doesn't include scale factor (as in "define"),
  17. but could support decimals as a distinct type in GDL (as ratios instead of
  18. floats?).  c_number should convert to integer, or check validity of uses.
  19.  
  20. Be able to mix .imf and .g files/forms, scan all .g files to collect
  21. images (but possible name conflicts...)
  22.  
  23. Add conditional loading via (if <xxx>) and (end-if <xxx>) forms.
  24. Syntax inside must be correct, unlike #| |#, but forms only read
  25. if disabled, symbols not interned or strings allocated.
  26.  
  27. Add an (x (disappear ...)) extension is that like appear, but
  28. schedules unit to vanish at the end of the given turn.
  29.  
  30. --Types and Objects
  31.  
  32. Clarify vision rules.  The true state of the world is a set of layers.
  33. For each cell in each layer, there is an apparent value, a date for
  34. that value, possibly prev values also.  Only need bit if value always
  35. accurately known once discovered.  Elevations and features unlikely
  36. to change, but weather, units, people, material often inaccurate.
  37.  
  38. Storms are considered to be very-high-density cloud.
  39.  
  40. Impl constant elevations and temps that don't need a whole layer (how
  41. to recognize?)
  42.  
  43. Allow some moves to use random mp, be able to specify +/- amounts.
  44. This is mp (and acp?) consumption only, does not affect validity of action.
  45. ut_mp_extra?
  46.  
  47. Define a notion of hp for bord/conn types, allows for interdiction
  48. and repair.
  49.  
  50. Side library should be able to allow multiple usages of some members.
  51.  
  52. Define a hallucination chance for some utypes:
  53. (sp-)looks-like u1 u2 -> n% is chance that u1 appears to be a u2
  54. and is recorded as such in a view.
  55. Note that code should ensure that only info about image is displayed
  56. rather than hallucination.
  57.  
  58. Use a slot (which?) to indicate variation radius of actual reinforcement
  59. position around  given xy.  Default of zero requires to be on actual xy.
  60.  
  61. Implement ZOC as a layer for ZOC ranges > 1.
  62.  
  63. Add a new layer coveralt to indicate the lowest altitude visible
  64. to any unit on the side.  Adjust along with basic coverage.
  65.  
  66. Add a "facing" bitmask that indicates the directions that a unit is
  67. "facing", or can operate in, add effects of facing vs non-facing.
  68. Come up with a display for this.
  69.  
  70. Events can have causes that they should be tied to, can use to
  71. enhance displays etc.
  72.  
  73. Write out a side symbol (if defined) for unit sides.
  74.  
  75. Add a (x (symbol <sym>)) to units that can be used to write a symbolic
  76. ref to unit when saving.
  77.  
  78. Maintain an in-supply bit for units.
  79.  
  80. Add a way to make incomplete units age and eventually vanish
  81. (cp-attrition?)
  82.  
  83. --Setup
  84.  
  85. Set growth algorithm so that growth always makes area known, if not
  86. actually expanded into.
  87.  
  88. Add a "spur" phase to road gen that connects to nearest road.
  89.  
  90. Add a chance for roads that just cross the area from one edge to
  91. another.
  92.  
  93. If a next dir for a road has a possibility to connect to a unit
  94. of a type that roads connect to, choose the dir to that unit over
  95. any open terrain direction.
  96.  
  97. Player mix test should be allowable_player_mix(assignmentindex),
  98. allows "scapegoating" a particular player if failed - gives
  99. a starting place for interface to fix.
  100.  
  101. Define parms for variability of initial materials using variation
  102. on fractal percentile synth method.
  103.  
  104. When using area restriction, need to be able to support both local
  105. and global coords of units being read in.
  106.  
  107. Change random renaming to offer a list of choices, but not to load
  108. all the emblems.
  109.  
  110. Liquid adjacent terrain types should always even out to same elevation
  111. (highest of all the competing elevations?)
  112. Flooding is always instantaneous if ttypes changed by a unit.
  113. Non-liquid border might or might not be a dike.
  114.  
  115. For unbalanced scenarios, provide a way for designer to indicate
  116. estimate of relative strengths.
  117.  
  118. Write interpretation of player-mix expressions.
  119. For now, just do <>= on player "templates", and boolean combos.
  120. (extend to side classes or even player/side assignments?)
  121.  
  122. Add density of occupants of indep units already placed.  Specify for
  123. both units that have to be occs and others that don't.
  124.  
  125. Need a way to coordinate all name gen for a single side -
  126. "foo" -> Fooland, Fooard, Fooards, Fooish"  Could also decide colors and
  127. emblem randomly, but wouldn't need to coordinate.
  128. Specify just *one* side name generator, extensions added in a standard
  129. way by an nlang.c routine.
  130. Predefine nonterminals side-name, side-noun, etc in side-namer grammar.
  131.  
  132. Add "earthlike" generator that borrows code, but is completely wired
  133. to do Earthlike stuff, including a semi-wired set of terrain types
  134. (use extensions to recognize by attributes rather than position,
  135. so that river deltas can be flat and swampy indep of how terrain type
  136. fits with others in a game design).
  137. Use tectonic code at some scales, erosion at others.
  138. Could base calcs on sphere, translate to world grid when done.
  139. Base on all real dimensions, so alt ranges wired.
  140. Parameters are area size/world.circumference for the scale
  141. (assume 100 km/cell if weird circumference),
  142. latitude of area, range of elevations (0 - 10000 meters),
  143. distance from coast (at center of area, allows specifying distance such that
  144. area can be 3/4 land, etc), average temp, average rainfall.
  145. For tectonics, use layers for plate num, move dir, and elevation.
  146. For small-scale, make random ridge/high point, erode down to lowest
  147. or to coast.
  148.  
  149. Could add recorded events that get played when their scheduled time
  150. arrives, so that a city could revolt or disappear at a preset time.
  151. Playing scheduled events should happen after acp/mp calc, but before
  152. players actually get to move.
  153.  
  154. Kernel should be able to do a system reset - all data structures
  155. and all allocation, so that a different game can be started up.
  156.  
  157. Add synth method for secret scorekeeper goals.
  158.  
  159. Use password to match up players when restoring into a different set
  160. of displays.  If no password, then will just accept a different
  161. assignment, perhaps warn for cmdline setup, flag in dialog boxes.
  162.  
  163. Any terrain-based variation, such as temperature, should check
  164. if need to represent varying values over area, don't need to
  165. alloc layer if not, *but* may need to quickly synth layer if
  166. terrain is added that *does* allow variations.
  167.  
  168. --Plans and Tasks
  169.  
  170. Still need way to set when unit can be run by side, and when it makes
  171. own decisions.
  172. Doctrine can set probability that unit will ask for
  173. orders when (a) all of its tasks are completed, (b) it decides to replan
  174. (decision interval is up to unit), and/or (c) something unusual happens
  175. and plan sounds an alarm.  Range of probs defined by game, so some units
  176. are never better than 50% to ask what to do.  Units acting on own use
  177. neither AI or player, but have a separate algorithm (same as the "no brains"
  178. AI algorithm - still executes from plan, but bypasses AI hooks)
  179. Uncontrolled units can be given orders, but have some chance of changing
  180. the plans arbitrarily.  Min/max of chance set by game, doctrine can set
  181. within those limits.
  182. "Control coverage" sets where units can be controlled, where act on own.
  183. Need some sort of event to notify when unit is in control range.
  184. Note that some units might be controlled by several sides at once.
  185. Lack of control means that units can be given plans and tasks,
  186. but will not always carry out the appropriate actions (could fail to
  187. act, or subst other actions)
  188.  
  189. "Intercept/defensive" plan directs units to patrol in an area, attacks any
  190. enemy unit (doctrine defines "enemy") that is of a type that can be
  191. attacked/harassed/blocked (ignore types that we can't do anything about!)
  192. Only some kinds of defensive units are interceptors, others are blockers
  193. or kept in reserve.  Blockers interpose rather than attack enemies,
  194. while reserves avoid contact until plan is changed.  Defn of "reserve"
  195. partly depends on attacker, so fighters intercept bombers but ignore
  196. battleships.
  197. Do as explicit decision in general defense plan.
  198.  
  199. Re-evaluate return if transport moving away too fast.
  200. Could have a "home" unit that is preferred if in range, such as
  201. fighters assigned to carriers.  Don't return to transports that
  202. don't have any fuel, unless there is no other choice.  Special-case
  203. grounding of aircraft if no supply in a base vs starvation of troops
  204. if no food in a base.
  205.  
  206. Exploration plan should set recon vs invasion type, use to decide
  207. about visibility while exploring.  Recon should attempt to gather
  208. knowledge without being seen.
  209.  
  210. If can refuel along a route if chosen correctly, subdivide move task
  211. so as to stop at refuel points.
  212.  
  213. Define a plan type that tracks/shadows units while staying out of sight
  214. as much as possible.  Would have to keep unit within view range but outside
  215. of its view range (and any other coverage, should write something to see
  216. whether a given cell might be visible to enemy), but may have to get
  217. closer to avoid losing trackee.  If unit being tracked seems about to
  218. do some damage, engage instead of shadowing.  May sometimes want to
  219. move to block or slow down trackee's escape.
  220.  
  221. Need special scenarios to be able to test all plan types accurately,
  222. should set up similar tests for all major parts of planning and AI code,
  223. each should ensure that all the code bits actually get executed.
  224.  
  225. Plans that fail to decide what to do are a potential problem, should
  226. eventually be replaced, but not too often or else warn about replacement.
  227. Track total usages as well as per-turn usage.
  228. Each successive plan for a unit should have a distinct serial number,
  229. display when displaying plan.  (units never share plans)
  230.  
  231. All units should get a chance to replan after acp/mp calculated
  232. but before anybody moves.  Should be fast, since nobody can move
  233. while this is happening.
  234. (Interface should be more obvious about this, so less confusion
  235. about turn change.)
  236. Give human players a chance to review plans made by high-initiative units
  237. before irreversibly made (flag review-plans, shows plans of units that
  238. are selected).
  239.  
  240. What about a task to not just resupply but to prepare for a long trip?
  241. Stock enough to make a crossing, etc.
  242. Check when doing an approach task, may want to push a "fillup" task.
  243.  
  244. Add notion of "supporting" another unit to doctrine, then unit could wake
  245. up and get involved automatically if combat nearby.
  246. Should specify by type & distance, as well as particular unit.
  247.  
  248. Do general org chart mechanism.
  249. Allow promoting any (or restricted type?) unit to be a commander, and
  250. assignment of units to commanders.  Cmdrs always move before other units,
  251. units can have orders to follow cmdr, cmdrs could have utype requisitions
  252. so production automatically goes to them.
  253. (Machine player could use this too.)
  254. Add a display to show how everything relates.
  255. Define a commander_decide_plan(cmdr, unit) or have cmdr make tasks directly?
  256. Each commander should have (or appoint) a deputy unit that will get its
  257. plan data if it dies.  If deputy dies, should work down through orgchart
  258. to find anyone, only giving up if entire group is gone.
  259. "Commander" plan is mod of other plan types, cmdr bit is for coordination.
  260. Cmdr plan includes an "ideal" mix of types to command.
  261. AI uses to set production, human gets told of cmdr unit's needs somehow.
  262.  
  263. If no AI or display on a side, what should units do?
  264. Will still have doctrine, attitudes, loyalties, so plenty to work from
  265. (include indepside in this but have no side-style coordination?)
  266. Can have and execute plans but no mechanism to change plans
  267. (i.e. can be read in but not altered thereafter - would need to flag?)
  268.  
  269. Should be able to set a "build rate" that is slower than "fast as possible",
  270. to avoid material depletion.  (i.e. use doctrine to set default rate of
  271. build actions, set actual rate in build task?)
  272. Define as amt of time to wait before starting build of next type (if the same).
  273.  
  274. --Actions
  275.  
  276. Add a separate chance for defender to capture attacker upon counterattack.
  277.  
  278. Add a material cost um_material_per_<type> and prerequisite
  279. um_material_to_<xxx> for all actions.
  280.  
  281. When "firing" aircraft from airbase, should recover most and lose a few.
  282. Generalized notion of fire interdiction would be useful, could subsume
  283. effects of jammers and suchlike.
  284.  
  285. To do < 1 cell/turn speeds, available acp should translate to
  286. occasional ability to move.
  287.  
  288. Some types of combat should not be able to reduce victim hp below a given
  289. level.  uu_min_hp_from_hit.
  290.  
  291. Define material-theft-per-contact(u1, u2, r) -> n in combat,
  292. material-loss-per-hit(u1, u2, r) -> n which is material completely lost.
  293. Some could be "resorbed" by terrain?
  294.  
  295. Some occ types should be able to prevent capture entirely, others don't,
  296. are just captured or destroyed themselves.
  297.  
  298. Some occ types could protect by intensifying counterattack.
  299.  
  300. Chance to surrender should be higher if damaged.
  301.  
  302. Occupants of captured units might get to stay if friendliness-to-enter
  303. allows it (?).
  304.  
  305. Detonation's effects should depend on altitude of detonating unit -
  306. compute the "actual" 3d distance.
  307.  
  308. Damage to multi-part units could be done by detaching wrecked-type
  309. instead of damaging all parts equally.  Do only if wrecked-type
  310. has appropriate sizes.  Only applies if wrecked-type has equal num
  311. parts to original type.
  312.  
  313. Could do multi-cell move actions as repn of hex entry until
  314. anything happens that requires a decision - blockage, etc.
  315. example: acp = 1, mp/acp = 10, allows single move of up to 10 hexes.
  316.  
  317. If a side wins a battle, then side's units involved should gain affinity
  318. for side, lose fear of other side.
  319. On losing side, units lose affinity for own side and increase fear of
  320. winning side.  Nonparticipants also affected, but less so.
  321. Affinity increases by positive acts, fear increases by negative acts.
  322. Betrayals should be detectable, have large effect.
  323. Need some implicit agreements about defense of units on a side,
  324. that players should not violate.
  325.  
  326. Side action limit should be a distinct value, decremented only for "manual"
  327. activity by player (first action after waiting for input?).
  328.  
  329. --Backdrop
  330.  
  331. Add ut_people_supply that is amount of supply gotten by unit if people in
  332. cell are on the same side.
  333.  
  334. Express need for limited supply as "n turns of supply before starvation"?
  335. Can lead to tough decisions about starving rear areas for sake of major
  336. offensives, etc.
  337.  
  338. in-length > 0 + ability to transfer from terrain means unit
  339. can get supply from cells other than own cell.
  340.  
  341. Should choose side to revolt to by counting
  342. number of units (of same type on each side?).
  343.  
  344. Siege surrender chance should be distinct from normal surrender chance.
  345.  
  346. [need to identify motives for demand, if rtype not needed
  347. for actual survival - dyes needed for "art" for example -
  348. might vary between sides/unit types?]
  349. [would need to define generic elasticity of demands,
  350. also the profit-seekingness of a population (vs conservatism, etc)]
  351. [can designate a material type as "money", so is used in exchange]
  352. [need some notion of credit too?]
  353. [units can effectively forage at some distance, distinguish foraging
  354. from actual production]
  355. [price should go up as material is transported further and further,
  356. and across varying difficulty of terrain...]
  357. [note that as sides, players can't force cell economy but can
  358. encourage it]
  359. [perhaps allow a side to fix a price artificially, let everything
  360. else readjust around it?]
  361. Sides can specify their trading relationship with other sides,
  362. by specifying the ratio of tariff to supply [etc].
  363. [trade relationship is indep of general trust/friendliness]
  364. [some type of agreements might be intrinsically enforceable, such as
  365. exchanges between units that cannot attack or capture each other]
  366. [exchange of material needs to relax fullness rules or be done as
  367. a sort of prim, else might not be able to trade when full]
  368.  
  369. Do supply lines, display unit's supplier and maybe supply route.
  370. Is there an efficient way to handle this?
  371.  
  372. To do large elev ranges, use bit 14 to indicate which range,
  373. define a global that gives ratio of ranges.  Also need a descriptor
  374. for text generation.
  375.  
  376. Add possibility to see all of a side's units if one of them is captured.
  377.  
  378. Could have a random dungeon digging process that adds to dungeon just
  379. ahead of player exploration.
  380.  
  381. Add plagues and famines as random events, impl could add layer to track
  382. spread, or else use an mtype that is amt of disease, but then larger amts
  383. of material should be more harmful.
  384.  
  385. Add weather.  Weather is a process operating on per-hex basis, affected
  386. by terrain type and elevation and maybe region.  Affects unit attrition,
  387. production, movement, combat, etc.
  388. Weather needs, temp, pressure, humidity, calculates new values of these
  389. and also has effects on visibility at multiple levels of atmosphere.
  390. Need to identify effect of each terrain type (and elevation) on each
  391. of these, also specify the rate at which changes occur.
  392. Effects on supply.
  393. Effect on vision, sensing in general.
  394. Each utype has preferred weather, gradual falloff in effectiveness.
  395. Add a generic "violence" value that summarizes wind/storm strength,
  396. relate to unit behavior.
  397. Use season to get avg temp, perhaps regulate motions as well.
  398. Should weather/climate be able to adjust terrain if it is off slightly?
  399. Impl via weather phenomena - overcast/clouds, rain/snow, storms/wind,
  400. temperature, humidity (compute value of phenomena, then compute phenomena's
  401. effect on units).
  402. Attrition increased by storms, also chance of accidents (for each accident
  403. type).
  404. Also chances of "random actions"?
  405. Could make some types of terrain temporarily impassable.
  406. Display should show fronts, major storms.
  407. Compute a daily temperature cycle based on number of daylight hours etc.
  408. Impl sequence should be fixed weather (weather state), random weather,
  409. seasonal weather, calculated weather.
  410. Implies that player-visible/settable state layers should be implemented first.
  411.  
  412. Distinguish "ideal" material level from "max" level, let
  413. some percentage of material move towards comfortable areas.
  414.  
  415. Scorekeeper can forbid the saving and restoring of a game, use in
  416. nonsecure situations.
  417.  
  418. Add a scorekeeper that looks at side view to decide whether player has
  419. discovered something that is to be searched for.  Should be able to
  420. require finding a lost city, etc.
  421.  
  422. Add option to scorekeeper to run on success/failure of an action
  423. matching given parameters, plus option to run on occurrence of a specified
  424. events, otherwise scorekeeper runs at either beginning or end of turn.
  425. Matching includes side and unit.
  426.  
  427. --AI
  428.  
  429. Track contacts with other sides on a per-theater basis.
  430.  
  431. Mplayer should compute which types are mostly likely to be in play
  432. at present, and at future times.  Can look at initial setup, construction
  433. times, etc, and ignore types that can't possibly appear.
  434.  
  435. Mplayer should attempt to compute numbers of units and material needed
  436. to achieve a goal, to some level of confidence, then set "buildup" plans -
  437. some units explore/patrol etc, then when buildup finished, should plan
  438. large-scale attack, from several directions if possible.  Reserve units
  439. should hang around transports, but not sit on them unless transport protected.
  440.  
  441. Use people sides to adjust theather boundaries sometimes. (how?)
  442.  
  443. If chance to surrender by siege > 5%, compute an ideal frontage, minimizes
  444. chance of units getting isolated.
  445.  
  446. Could do formations by reshaping theaters.  Units mass on edge, don't go past
  447. until AI directs an offensive.  If offensive successful, AI adds gains to
  448. theater.
  449.  
  450. If returning to a moving transport, and transport destination is further away,
  451. push a "wait" or "rendezvous" task onto transport's queue.
  452.  
  453. Be able to change theater size and shape as the situation changes,
  454. let theater develop to optimal size.
  455.  
  456. For each theater, distinguish
  457. recent vs older sightings, with exponential backoff (1-2 turns ago,
  458. 3-5, 6-10, 11-20, etc).
  459.  
  460. AI should have a chance_to_own_one_of_type(side, side2, u) that the side's
  461. current estimate of the likelihood of the given side2 owning at least one
  462. unit of the given type.
  463.  
  464. Very small theaters should evaporate (how to recognize?).
  465.  
  466. Need special code to know how to defend bridgeheads, recent captures,
  467. etc.  Reduce theater size or focus on immediate vicinity.  Own units
  468. in "enemy" theater (define) should be defended against the most
  469. immediate threats.  Look around for threats or potential threats.
  470. Assign best units to deal with threats.
  471.  
  472. Need better weighting of hit prob vs death prob, also relate to goals,
  473. so unit with low hit prob will still attack another unit if it can win
  474. the game by doing so.  (implies we need to evaluate importance of goals,
  475. nearness to achieving them)
  476.  
  477. Have machine player compute general dependency chains for its strategy.
  478. For instance, "need miners to produce uranium from mountains
  479. to build nukes to attack cities".
  480. Should be "lazily" computed, as needed to achieve basic goals.
  481. Strategy code works by calculating a plan that consists of steps
  482. to reach the goals.  Plan is sufficiently detailed when side can
  483. tell each unit what to do, or doctrine has the same effect.
  484. Not always totally deterministic, how does this work?
  485.  
  486. Unit type analysis should be based on average outcome, plus worst/best-case
  487. outcomes if not maybe not expecting enough action to let things average out.
  488.  
  489. To estimate materials, scan world, for each unit image, add survival
  490. needs to min est, stockpile - avg operating costs to likely est,
  491. total storage capacity to max est.  Can use actuals for own and allies.
  492. Similar for terrain and population.
  493.  
  494. Unit first spotting human enemy should disappear as quickly
  495. as possible, might escape before human notices. (exploratory plan only)
  496. Purely exploratory/recon units should generally avoid combat, try to escape
  497. and stay hidden if possible.
  498.  
  499. Resign if goals (as derived from scorekeepers) are provably unachievable.
  500.  
  501. Theaters of < 6 cells should be removed entirely.
  502.  
  503. Do base construction as 1) moving to construction site, 2) building, and
  504. 3) carrying to final site.  (Must verify that base or parts of base can
  505. be carried.)
  506.  
  507. When enemy unit spotted in a zone, decide if unit is part of larger
  508. group (like a country), what kinds of units might be present (similar,
  509. sessile, etc).
  510. If unit is isolated, decide if it is a threat in any way, if so, make
  511. a goal "enemy gone from x,y" and assign units to work on this goal,
  512. with types and numbers sufficient to the job.  Can borrow from nearby
  513. theater if not too time-consuming.
  514. If group, decide importance (home country being most important),
  515. also assign # units, maybe make theater, track strengths, # units
  516. enroute, and # still needed.
  517. Distinguish units that are dangerous alone and ones that are carriers.
  518.  
  519. Machine player should attempt to infer other sides' strategies.
  520. Define an "importance" of activities that gets divvied up among
  521. subcommanders, so overall plans can be set aside temporarily while
  522. individuals deal with immediate threats.
  523.  
  524. Machine player code should look for "choke points" that are standard
  525. routes between important places and around obstacles.  Calculate from
  526. world and utypes, share among all machines (don't use if haven't seen
  527. yet!).
  528.  
  529. Write a stdplay.c that is only applicable if game is similar to standard
  530. game (examine set of types, but still need to doublecheck numbers).
  531.  
  532. Eventually add code to negotiate for neutrality/ally status.
  533.  
  534. --Coding
  535.  
  536. Write statistics as comments when saving a game, and when requested
  537. by designer.
  538.  
  539. Be able to save individual properties along with ids to match with units.
  540.  
  541. Simplify module-writing flags, eliminate need to set two flags ever.
  542.  
  543. Add option to save a map rotated, at least by 60-deg increments.
  544. 60 left, 1st hextant formula is y' = x + y, x' = -y, etc.
  545.  
  546. Use prob_fraction more often, where applicable.
  547.  
  548. When lots of mallocs being recorded, either maint enough space to
  549. record all, or else drop/combine smaller totals to make room to
  550. record the big allocs.
  551.  
  552. Write dice specs as dice specs, not large numbers.
  553.  
  554. Use 16-bit indices to an array of pointers to units.
  555.  
  556. Add a new re-id slot to units, use to hold new id when renumbering.
  557.  
  558. Allow the use of a proper vararg implementation (ANSI?).
  559.  
  560. Add a kernel routine notify_all that goes to all players with displays,
  561. requires ack from all, support voting and timeouts.
  562. Use in x/xt version for run errors etc.
  563. (is this really useful?? could be a general multi-player alert
  564. with voting/ack requirements)
  565. multi_alert(msg, sides, [minquorum, mintopass], timeout)
  566. multi_query
  567. update_multi_query_display
  568. interface calls ack_multi_query
  569.  
  570. Define zzz-s-u-n as cache for shortest name (down to 1 char if possible,
  571. but confusing if only some have one-char names, others are all-but-one
  572. char of name, etc)
  573.  
  574. Define a can_occupy(...,exclunit) that indicates room if given other
  575. unit is *not* counted (since it will be removed shortly, for instance)
  576.  
  577. Make a bit vector of allowed sides for each type.
  578.  
  579. Define performance as a sort of ratio to specmarks, so benchmark game is
  580. known to last 2 minutes on a 100-specmark machine, etc.  Use -R 1, only
  581. "real" games, various mixes of AI, little/no interaction.
  582.  
  583. Doctrine consists of a list of modifications to a single doctrine object
  584. that is final answer (no doctrine relationsships).  Can always clone a
  585. doctrine but then is severed from original.
  586.  
  587. Flush unit->prevunit links if can't find a use for them.
  588.  
  589. Add general check on parameter bounds as given in *.def (warnings only
  590. until all values corrected).
  591.  
  592. Keyword table(s) should be sorted, can do binary search then.
  593.  
  594. Define foo_text(buf, n, xxx) where n is available space for description,
  595. return actual length of text in buffer.
  596. To get strings, define foo_string(xxx), which returns a 0-terminated string.
  597.  
  598. Test availability of types always, check through code for usages.
  599.  
  600. For all units on a side, keep sorted by type, keep ptrs to start of each
  601. type, use to index faster.  Could even maintain separate chains for each type.
  602. Define a for_all_side_units_of_type(side,type,unitvar) iterator.
  603.  
  604. Implement a convex region finder that works by picking random points as seeds
  605. and grows out from those.  Sides have to be "locked" if entire side can't
  606. all grow - combo of locked and unlocked sides allows region to become
  607. parallelogram, triangle, etc.
  608. How should borders and connections affect generic region finding?
  609. Grow from random points until about 3/4 of cells in regions, then scan
  610. down to finish off.  (Could leave single points as "their own regions",
  611. not alloc any region structs.)
  612.  
  613. General path objects consist of multiple segments, each with start/end
  614. point and a validity test (that can be done at any time).  Also include
  615. a bit with segment saying "shortest" or just "nonincreasing distance".
  616. Should be possible for a path to say "impossible" for some segment??
  617. (consider path that consists of land travel segments plus a sea hop
  618. that needs a ferry of some sort - path is still valid and useful.)
  619.  
  620. Regions should
  621. point to super-regions, not necessarily contained.  Include bits for
  622. caching connectedness, terrain percentages, etc.  Add region layer to
  623. regular map (each hex can only point to one region, multi-stuff must be
  624. between regions).  Need commands to define and display regions.
  625. Regions never overlap, must subdivide and make subregions be included
  626. in several super-regions.  True for all regions, don't do multiple
  627. "region layers" (unless significantly more efficient?  check stats).
  628. Add region layer for mplayers that need to explore, add to layer
  629. as mplayer sees stuff.
  630.  
  631. Theory of networked Xconq is that all copies synchronize on actions
  632. and random seeds, then do run_game and get identical results.  Each
  633. program will broadcast its planned actions, then wait until each other
  634. program indicates that it has sent all that it plans to.  When a program
  635. has received "done" from all others, then it can safely execute.
  636.  
  637. Can collect interface/kernel requirements by trying to link one without
  638. the other.
  639.  
  640. For any routine in the interface that tweaks in the kernel, have to
  641. siphon it off to the network also.  Do via compiling interface with
  642. augmented calls, so kernel code need not be modified to know about
  643. networking.  On receiving side, input mux includes a decoder that
  644. invokes kernel routines (note that decoder has to know about calls
  645. that not all interfaces actually support, since less-powerful
  646. interface may get kernel-changing messages from more powerful interface).
  647.  
  648. Come up with a way to prove that mplayer doesn't cheat by looking
  649. at structs?  Could have a have a "sneaker" that is always invisible,
  650. never attacked unless mplayer cheats.
  651.  
  652. Add tests involving two communicating skelconqs with preset port
  653. numbers, use to test networking behavior.
  654.  
  655. Add a protocol version number etc so that mismatched versions can't
  656. connect.
  657.  
  658. Compress material layers by including info about # bits (1,8,16).
  659.  
  660. Define a "text buffer" object that is variable-size, resizes as needed,
  661. do all printfs into it.
  662. To guarantee integrity, program could display checksum or signature to players
  663. upon startup, so they can agree as to identity of program.
  664.  
  665. To do play-by-mail games, need to be able to save an optionally encrypted game
  666. and pass along to next player -
  667. player info includes some sort of bit indicating
  668. where to send to. (player-address slot)
  669. Encrypted game should retain game-module form as plaintext,
  670. include a "password" slot, then all numbers appearing at "top level" will be
  671. decrypted, random forms still read normally.
  672.  
  673. Optimize mapping side and unit ids back to objects themselves.  Use hash
  674. table for units, direct table for sides.
  675.  
  676. --Interface
  677.  
  678. Draw some features by using boundaries, of different appearances.
  679.  
  680. Need a way to indicate relative order of sort keys in list windows.
  681.  
  682. [Mac] Don't force update or redraw of windows if clicking a button
  683. has no visible effect (wrong mag for instance).
  684.  
  685. [Hint] Never draw things that xform to 0 or 1 pixel areas.
  686.  
  687. Add view option to lists to summarize rather than enumerate.
  688.  
  689. When in mono, allow choice of small numbers or letters for side, instead of
  690. emblem.
  691.  
  692. At high mag powers, draw people emblems near borders of hex instead of in
  693. middle.  (when emblem width < 1/4 cell width)
  694.  
  695. Don't draw side emblems on borders with terrain that can't have any people
  696. (sometimes good, sometimes not - how to tell?)
  697.  
  698. Define a -h <n> that sets up and waits to get pings from human players.
  699. Like -e <n>.  Kernel only has "wait for <n> remote players", cmdline
  700. does the -h part. -wait <mins> to say how long to wait before going
  701. ahead, also allows players to get impatient and start anyway.
  702. Ideally, the startup host gets a window or command interface
  703. to control the startup process, see who is in, perhaps edit
  704. display specs.
  705. All player specs should be able to add "+n" to adjust advantages,
  706. as in -e 4+2, +2 alone (one mplayer, +2 advantage?)
  707.  
  708. Define some common part of imf reading and interpretation in kernel
  709. or a common support lib, extend basic image structs with interface-specific
  710. detail:
  711.     struct imf { common com; specific icon,... }
  712. Common includes size ranges and maybe depths.
  713.  
  714. Some images in imf may be precalced for a hex or other shape,
  715. need to indicate specially.
  716.  
  717. Game should be able to spec relative or absolute widths of borders
  718. and connections.
  719.  
  720. If multiple conn/bord types, interfaces should draw offset from each
  721. other.
  722.  
  723. Should be able to, from cmdline, list available player slots in a remote
  724. game without actually trying to get in.
  725.  
  726. (is sort of done now)
  727. Allow adding a hole or mask to add side emblem to units (plus offset?).
  728. Specify as (image ... (emblem-space x y w h) ...)
  729. Also, each image can declare that an emblem is already embedded, as
  730. ... (has-emblem <emblem-name>)... (would still draw actual emblem if
  731. it didn't match the embedded one - leave embedded one, may be useful info)
  732.  
  733. Should be able to parse dates in commands,
  734. omit parts that are same as current value (such as year).
  735. Date string function should cache stuff, so not always allocing new
  736. strings.
  737. Length of a turn specified as "<n> <unit>" where <unit>
  738. is known to calendar type.
  739. Robustify the base date parsing.
  740.  
  741. Add a text parser etc for specifying units and types.  parse_[urt]type,
  742. parse_unit should be able to recognize ambiguous matches, either return
  743. # results or report of multiple, be able to process each independently,
  744. put in dialog, etc.  parse_feature to locate geo geatures by name.
  745.  
  746. Need keywords for images to tie less specific images at smaller
  747. scales to more detailed ones - "su-85" -> "tank", etc.
  748.  
  749. Kernel should deliver basic formatting info in help text, let interface
  750. digest - need line breaks, text fill, tabs/tabstops, emphasis/bold (use
  751. ^B,^P,^I chars?).  Perhaps some way to name a picture and let interface
  752. fill in actual picture.
  753.  
  754. Do something in general for reporting destinations, choices are
  755. raw coords, dir/dist, or a dest name of some sort (unit or region).
  756. Useful to have optional map scale to report distances in miles etc?
  757. Examples: "in xxx country" (needs defn of country)
  758. (define gvar "start-area-name" that gives name?)
  759. "NE of country" "E of Foo Bar" "in <region>"
  760. Function is position_desc(buf, side, x, y), where side==NULL means
  761. do for omniscient side,.
  762. also define position_desc_relative(buf, side, x, y, x2, y2).
  763.  
  764. --Library
  765.  
  766. Change stdunit so that only towns and cities count, not armies?  Will
  767. require better defensive operations.
  768.  
  769. Skelconq should examine lib.imf directly during setup, report
  770. on which images were found for the game being loaded.
  771.  
  772. Collect all old games, do partial translations.
  773.  
  774. Image tools should be able to study colors and colorized images
  775. usefully somehow.
  776.  
  777. Let images refer to colors by name.
  778.  
  779. Make new world maps that use connections for straits and rivers.
  780. Distinguish navigable/unnavigable rivers?
  781. (extra layers should be optional - could do "ifdef river type")
  782.  
  783. Add notion of named palettes to .imf files, in form
  784. (palette name color1 color2 ...)
  785. then images can refer to palette by name and colors by index.
  786.  
  787. Modify standard game to be more resource-bound, supply used up
  788. faster, all units must be kept supplied, need to build strings of
  789. bases to get supplies out to where needed.
  790.  
  791. Write a ww2-std-pac-42 game.
  792.  
  793. --Game Ideas
  794.  
  795. "Quest"
  796.  
  797. For one player usually, starts out as a vagabond with limited materials.
  798. Either convert self to higher "rank", or else have improved capability
  799. via experience points and more equipment (but what would "equipment" be
  800. good for exactly?).
  801. Can capture other humans, animals, etc, use as assistants of variable
  802. loyalty.
  803. Terrain is standard.  Include rivers and roads, with significant effects.
  804. Units would be various cities/towns/villages, usual (wandering?) monsters.
  805. Could have a machine-run side that seeks to capture/kill player, like a
  806. police force or army (or assassins?).
  807. Have ships for crossing oceans (but need to "buy" somehow, and if in town,
  808. town should be on coast).
  809. Include weather/seasons with significant effects.
  810. Need unit/material as object of quest, perhaps different kinds for
  811. different games.
  812.  
  813. (Need to be able to enter/leave neutral places without capturing, but also
  814. be able to accept surrender - perhaps a notion of "if a place is indifferent
  815. to your existence, can interact without combat".  Extend to hostile places
  816. that you can sneak in and out of, though at some risk.)
  817.  
  818. Should predefine all sides(?), but allow multiple adventurers and only one
  819. monster side - lock this side so players can't take it (but not always?)
  820.  
  821. To make a game of graduated difficulty, make a long horizontal world, put
  822. player at one end, goal at other, lots of monsters in middle,
  823. tougher ones further away.  (Monsters should move around a little,
  824. but not overwhelm player instantly - could make "electric fences" of
  825. ttypes crossable by player but not monsters, so even fast monsters confined.)
  826. Would look like a string of sausages - 1600x40 world is approx equiv to
  827. 40-level dungeon.
  828. Won't be computed incrementally though, but could schedule creation
  829. of high-level monsters to be later in game, make a snowball effect where player
  830. faces huge numbers of monsters if too slow at first.
  831.  
  832. To make a race game out of this, make a star shape with players at end points
  833. and goal in middle.
  834.  
  835. "Medieval Diplomacy" a la Kingmaker
  836.  
  837. Each player is a lord/lady with coat of arms.
  838. Few battles, much maneuvering.
  839. More alliance machinery?
  840. Need rules/state for varying degrees/types of alliance, could affect
  841. mutual transport, control, temporary vs permanent gift, etc.
  842. Can move armies around, raise/lower taxes, manage rebellions, wheel/deal.
  843. Players have a chance of dying accidentally or of old age.
  844. Can players be taken prisoner themselves and try to buy their freedom?
  845. (Because if player is killed, possessions revert to neutral or to ally
  846. rather than being acquired by capturer.)
  847.  
  848. (Need primitive for "exchange", theory is that actual individuals arranging
  849. trade can prevent cheating on the spot, perhaps include a "chance of cheating
  850. success" plus "attempt-to-cheat-p" that each player can set.)
  851.  
  852. (Be able to have "materials" like age or heat or poison that are deadly if you
  853. accumulate too much? would need a excess-death-chance that is like starvation)
  854.  
  855. "Modern War"
  856.  
  857. Develop a modern-day military game.
  858.  
  859. "Today"
  860.  
  861. An all-out simulation of the modern world at a 1/2 degree scale,
  862. with each indep country as a side!  Double size of earth map, stretch
  863. slightly further north, add cities and population to account for everybody.
  864. Would need high-density cities, factories, etc.  Don't worry about size of
  865. game, use it as a test of massive scale.
  866.  
  867. Should have versions at several levels of detail that share same basic
  868. concepts.
  869.  
  870. One version should be like PSL empire in concept.
  871.  
  872. "Space Empires"
  873.  
  874. Like Spaceword HO or GB, based on thinly scattered solar systems with
  875. planets as occupants, ships/cities occs of planets.  Deep space move
  876. very slow (but not less than 1 hex/turn?), but could enter/leave gate
  877. units more quickly if entry of non-adj unit allowed.
  878. Solar systems are always-seen, but would need to explore planets more
  879. carefully (planetary surfaces not plausible tho).
  880. 1-month turns??
  881.  
  882. "Corporations"
  883.  
  884. [could make a game based on corporations that have units that are
  885. factories etc, should be able to buy and sell them]
  886.  
  887. [most elaborate might be to allow corporations to coexist with
  888. countries (what does that mean?)]
  889.  
  890. --More
  891.  
  892. At end of a turn, display summary/histogram of action/task/plan types
  893. and outcomes.
  894.  
  895. Add option to rotate layer data when saving.
  896.  
  897. Need a general (all-interface) strategy for guaranteeing image
  898. consistency on screen.
  899.  
  900. Should be able to specify a rotation when saving a layer.
  901.  
  902. Should all probabilities be allowed to have two decimal places?
  903.  
  904. Decide when sides should be able to look at other units' hp.
  905.  
  906. Decide if/how country growth and initial strength should interact.
  907.  
  908. For small-part-of-world areas, define daylight-zone and twilight-zone(?),
  909. which default to 1/2 and 1/12 respectively.
  910.  
  911. Be able to expand country borders by building or occupying outside original
  912. country.
  913. ut_add_people_chance n%
  914. ut_add_people_adj_chance n%
  915.  
  916. To decide about revolt, define:
  917. u_[indep_]revolt_chance .01n%
  918. uu_[indep_]surrender-chance .01n%
  919. uu_surrender_range n
  920.  
  921. Only certain types of units should be able to have mixed feelings, alloc
  922. loyalty objects for these.  Loyalty objects all consistent size, needed only
  923. if more than two feelings possible, else use 4-byte slot for values.
  924.  
  925. Define a "process" object:
  926. (process <name>
  927.   (agents <unit-type(s)>)
  928.   (automated-rate n1)
  929.   (manual-rate n2) ; + acp to do?
  930.   (inputs <material-types>)
  931.   (outputs ...)
  932.   (catalysts ...)
  933.   (terrain-effects ...)
  934.   )
  935. Process agent units are optional.
  936. May want to add "tooling" of units to do a process.
  937.  
  938. Restrict Lisp syntax knowledge to small part of code, allow translation
  939. to other languages.
  940.  
  941. Implement delayed views, where a unit that is out of contact with the side
  942. keeps own view data and only merges when in contact with side again.
  943.  
  944. Add an "engineering" plan type, with subtypes "make-access" and "block-access".
  945. Engineering units build access routes
  946. by adding/removing/modifying terrain, or by building units that serve
  947. only as bridges.  Should be able to build multi-cell/unit chains in
  948. difficult cases.  Examples: could bridge one blocking cell by a) building
  949. a transport unit that ferries, or b) building two connections.  Could
  950. bridge a single blocking border by building a connection or by removing
  951. border.  Want to do this for any cell that is very expensive to cross.
  952. To implement, plan should look for cheapest route assuming that blockage
  953. has been negated, then build bridges for that route.
  954. Engineers should also know how to build roads, do that if road movement
  955. is much faster (such as doubled) than normal movement.
  956.  
  957. Add a perspective view, of selectable position, direction, and height.
  958. Easier if only one of six dirs allowed, can't go higher than unit if
  959. using LOS viewing.
  960.  
  961. WWII scenario should be able to have a "neutrals" side that resists
  962. involvement.  Attempts to attack neutrals should have some consequences.
  963.  
  964. Add a type of random event where a side or group of units can change
  965. to an active side all at once, reflects changing politics, requires
  966. maintenance of reserves, etc.
  967.  
  968. To do patrolling/picketing, space units so that few or no holes in coverage.
  969. In theater being covered, check view dates and send units to update oldest
  970. information - should be closest unit or one assigned to cover.  Could therefore
  971. have a patrolling unit that only moves very little since its view range covers
  972. nearly entire assigned area.  Allowable age of views depends on what sort of
  973. surveillance is avail, how many units are assigned.
  974.  
  975. Derive acceptable risks from goals - unit that is crucial to game should not
  976. risk self, disposable types can be sacrificed.
  977.  
  978. For each type of goal in game, decide which units help accomplish and how
  979. well, which units support indirectly, etc.  Also classify by short/long term
  980. value - short-term is 5-10 turns or 1/10 of game, long-term is length of game.
  981.  
  982. Set initial theaters to be identical to initial search zones, gradually modify
  983. to match terrain better.  (Theaters divide down middle of seas, etc.)
  984. Initial search zones should be from center of country in six dirs, subdivided
  985. by distance (increment should be 10, speed of fastest unit, 1/10 of world).
  986. Can use knowledge of country size to optimize search, by spacing out explorers,
  987. not filling in details of terrain until later (is diff, low-priority goal,
  988. maybe subsumed by patrolling).
  989.  
  990. Construction calculations should prefer multi-purpose units, but randomize if
  991. values close together.  (Test by making game variants with ultra-powerful
  992. units, should see mplayer shift to building all the time.)
  993. Each goal should be characterized timewise, so mplayer can start builds and
  994. have units ready when goal becomes relevant.
  995.